home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9381 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: anvil.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 29 Feb 1996 15:10:53 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4h5bptINN9oi@anvil.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <1996Feb22.005518.13396@leeweyr.sccsi.com> <4gvrffINNlqo@anvil.ugrad.cs.ubc.ca> <SPENCER.96Feb29102241@zorgon.ERA.COM>
  9. NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca
  10.  
  11. In article <SPENCER.96Feb29102241@zorgon.ERA.COM>,
  12. Spencer Allain <spencer@ERA.COM> wrote:
  13.  >In article <4gvrffINNlqo@anvil.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
  14.  >
  15.  >   What is intrinsically unsafe about C? I could write a strict,
  16.  >   standard-conforming, anally-retentive program in any language that could kill
  17.  >   people (maliciously, of course).
  18.  >
  19.  >   Software which has life-threatening consequences shoud not be left to something
  20.  >   that sacrifices intimacy with hardware for some higher purpose that has more to
  21.  >   do with bureaucracy than anything else.
  22.  >
  23.  >   And it should certainly not be written in some poorly standardized language,
  24.  >   for which no two implementations are in agreement. C is governed by an
  25.  >   ISO standard, which, if adhered to, lets a strictly conforming program
  26.  >   translated by a strictly conforming implementation yield well-defined results.
  27.  >
  28.  >   I don't think you can say the same for Ada or C++.
  29.  >   -- 
  30.  >
  31.  >Whoa there.  I think somebody has been feed a lot of misinformation.
  32.  >
  33.  >Yes, C has an ISO standard, but this is only one aspect of the safety
  34.  >issue.
  35.  >
  36.  >What is intrinsically unsafe about C?  I'm not about to rehash what's
  37.  >been said a million times, but any programming language that allows
  38.  >you to walk all over memory without any checks is considered
  39.  >intrinsically unsafe.
  40.  
  41. This is not necessarily true of an implementation. Accessing memory outside of
  42. a static, automatic or malloc-ed object is undefined behavior under the
  43. standard. It is not condoned. Nowhere does the standard encourage
  44. implementations to _not_ implement run-time and static checks for such
  45. violations.
  46.  
  47. Many compilers can perform pointer dereference checks through inline code.
  48. There are ways to debug use of heap storage.
  49.  
  50. You are confusing the language specification with the implementation. The C
  51. specification does not call for the ability randomly access memory. The only
  52. way to legally manufacture pointers is by taking the addresses of named
  53. objects, using the standard defined function malloc() or through pointer
  54. arithmetic (adding an integral displacement to an existing pointer---an
  55. operation which yields undefined results if you try to create a pointer outside
  56. of an object). You aren't even legally allowed to subtract two pointers that
  57. don't reference the same object, even if they have compatible types.
  58.  
  59.  >And who told you that Ada hasn't been standardized?
  60.  
  61. Oops. I should not have included Ada in that, just C++. My apologies. Of course
  62. Ada is standardized!
  63.  
  64. If C is ``unsafe'', C++ is lethal.
  65.  
  66. Whether C is more or less unsafe than Ada is truly debatable.  A
  67. standard-conforming, _quality_ implementation of either language coupled with
  68. adherent programs subject to rigorous quality control is suitable for
  69. safety-critical software.
  70. -- 
  71.  
  72.